Centralize `enable` option handling in the factory by watson · Pull Request #324 · DataDog/build-plugins

watson · 2026-04-19T06:01:01Z

What and why?

The six user-facing plugins (apps, error-tracking, live-debugger, metrics, output, rum) each had a divergent implementation for resolving their enable config boolean:

Two code patterns: apps and live-debugger used explicit ?? nullish coalescing, while the other four used a spread-override trick (enable: !!config[KEY], ...config[KEY]) that relies on property ordering.
Inconsistent validation: Only live-debugger rejected non-boolean values; the rest silently coerced.
Incomplete docs: output and metrics documented default: true (misleading — it's false when the config block is absent), and error-tracking had no enable section at all.

This PR makes the factory the single owner of enable resolution so every plugin shares one set of semantics — and individual plugins stop having to think about enable at all.

How?

Factory becomes the gate (@dd/factory):
Each user-facing plugin's <configKey>.enable is resolved once in the factory's plugin loop, before the plugin's getPlugins is even called. If it resolves to false, the plugin is never instantiated, never validated, never hooked in. As far as the rest of the build is concerned, it doesn't exist.

Shared helper (@dd/core/helpers/options):

resolveEnable(options, configKey, log) — single source of truth used by the factory. Emits a deprecation warning (once per key) when a non-boolean value is passed, coercing it with !! to avoid breaking existing users. A TODO(next major) marks the coercion site for removal.

Plugins simplified:

getPlugins no longer has an if (!validatedOptions.enable) return [] guard.
validateOptions no longer calls resolveEnable; apps, output, and metrics no longer need a log parameter at all.
Each <Plugin>OptionsWithDefaults type drops enable — the factory guarantees it's true when plugin code runs, so it's meaningless in the resolved shape.
live-debugger now uses the same soft coercion as everyone else (with a deprecation warning) instead of throwing on non-boolean values. Strict rejection moves to the next major along with the others.

Integrity tooling:
The #configs-injection-marker block now emits [name, CONFIG_KEY, getPlugins] triples so the factory's enable loop stays in sync as plugins are added or removed. The create-plugin scaffolding follows the same pattern (no enable guard, no enable in OptionsWithDefaults).

Documentation:

Every user-facing plugin's README now has an identical ### <key>.enable section with the correct default wording: true when a <key> config block is present, false otherwise.
error-tracking gained its missing enable section and TOC entry.
live-debugger's README updated to reflect the soft coercion (was "Must be a boolean").

Tests:

Factory gains integration tests covering: missing key → skip, present key → include, enable: false → skip, enable: true → include, non-boolean → coerced + included.
Per-plugin enable tests removed from validate.test.ts / index.test.ts (no longer the plugin's contract).
live-debugger's strict-rejection tests removed (no longer the contract).

watson · 2026-04-19T06:01:14Z

Centralize enable option handling in the factory #324 👈 (View in Graphite)
Add live-debugger plugin #296 : 1 other dependent PR (#325 )
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

yoannmoinet

Looks mostly good.

I wonder if we could handle one level higher than just resolveEnable and have something like a global validateOptions, that would, for now, validate enable.

It would be called from each plugin, but would be implemented, tested and documented just once.
Since this is a standard, this can be documented just at the root, once, and not for each individual plugin.

Or alternatively, handle this at the factory level directly, where we also have an validateOptions too.

build-plugins/packages/factory/src/index.ts

Lines 176 to 190 in 00679a8

    
           for (const [name, getPlugins] of pluginsToAdd) { 
        
               context.plugins.push( 
        
                   ...wrapGetPlugins( 
        
                       context, 
        
                       getPlugins, 
        
                       name, 
        
                   )({ 
        
                       bundler, 
        
                       context, 
        
                       options, 
        
                       data, 
        
                       stores, 
        
                   }), 
        
               ); 
        
           }

This way, plugins themselves don't even have to handle it.
The standard is applied by design.

I think I prefer the factory approach after all.

WDYT?

Introduce a shared `resolveEnable` helper in @dd/core that all six user-facing plugins now use to resolve their `enable` config flag. This replaces the two divergent patterns (explicit `??` vs spread- override) with a single greppable call site per plugin. Non-boolean values continue to be coerced for backwards compatibility but now emit a deprecation warning so strict validation can land in the next major. live-debugger retains its existing hard rejection via the companion `validateEnableStrict` helper. Also fixes the misleading `default: true` wording in the output and metrics READMEs, adds the missing `errorTracking.enable` docs section, and authors a full README for the rum plugin (lost in the sourcemaps extraction refactor of 804f917).

jakub-g

I defer review to Yoann here :)

oliverli · 2026-05-13T12:06:31Z

@cursor review
@codex review

chatgpt-codex-connector · 2026-05-13T12:10:56Z

Codex Review: Didn't find any major issues. Breezy!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

oliverli

looks good for apps

watson mentioned this pull request Apr 19, 2026

Add live-debugger plugin #296

Merged

watson mentioned this pull request Apr 19, 2026

Validate optional live-debugger version #325

Merged

Base automatically changed from watson/DEBUG-5291/add-live-debugger-plugin to master April 20, 2026 13:42

watson force-pushed the watson/DEBUG-5291/fix-enable branch from 430542d to dd508cf Compare April 20, 2026 14:58

watson force-pushed the watson/DEBUG-5291/fix-enable branch from dd508cf to 00679a8 Compare May 12, 2026 05:31

yoannmoinet reviewed May 12, 2026

View reviewed changes

Comment thread packages/plugins/apps/src/validate.test.ts Outdated

Comment thread packages/plugins/rum/README.md Outdated

watson added 2 commits May 13, 2026 07:39

Address review comments

f847e1a

watson force-pushed the watson/DEBUG-5291/fix-enable branch from 00679a8 to f847e1a Compare May 13, 2026 05:46

watson changed the title ~~Standardize enable option handling across all plugins~~ Centralize enable option handling in the factory May 13, 2026

watson marked this pull request as ready for review May 13, 2026 05:54

watson requested review from a team as code owners May 13, 2026 05:54

watson requested review from jakub-g, oliverli and yoannmoinet and removed request for a team May 13, 2026 05:54

jakub-g reviewed May 13, 2026

View reviewed changes

oliverli approved these changes May 13, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Centralize `enable` option handling in the factory#324

Centralize `enable` option handling in the factory#324
watson wants to merge 2 commits into
masterfrom
watson/DEBUG-5291/fix-enable

watson commented Apr 19, 2026 •

edited

Loading

Uh oh!

watson commented Apr 19, 2026 •

edited

Loading

Uh oh!

yoannmoinet left a comment

Uh oh!

Uh oh!

Uh oh!

jakub-g left a comment

Uh oh!

oliverli commented May 13, 2026

Uh oh!

chatgpt-codex-connector Bot commented May 13, 2026

Uh oh!

oliverli left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	for (const [name, getPlugins] of pluginsToAdd) {
	context.plugins.push(
	...wrapGetPlugins(
	context,
	getPlugins,
	name,
	)({
	bundler,
	context,
	options,
	data,
	stores,
	}),
	);
	}

Conversation

watson commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What and why?

How?

Uh oh!

watson commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yoannmoinet left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jakub-g left a comment

Choose a reason for hiding this comment

Uh oh!

oliverli commented May 13, 2026

Uh oh!

chatgpt-codex-connector Bot commented May 13, 2026

Uh oh!

oliverli left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

watson commented Apr 19, 2026 •

edited

Loading

watson commented Apr 19, 2026 •

edited

Loading